X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C71FB1.FA8A0605@onstor-exch02.onstor.net>; Thu, 14 Dec 2006 10:59:27 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C71FB1.FA8A0605"
Content-class: urn:content-classes:message
Subject: RE: CLI Refactoring Project: cli command list and parsing library functional spec
Date: Thu, 14 Dec 2006 10:59:27 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E01C0AC84@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E019F5929@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CLI Refactoring Project: cli command list and parsing library functional spec
thread-index: AccZlzWMYS/mghA2SHaeZ+4lZpH04AGGmuWQ
From: "Jonathan Goldick" <jonathan.goldick@onstor.com>
To: "Charissa Willard" <charissa.willard@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>
Cc: "Ravi Kumar \(HCL\)" <ravik@onstor.com>,
	"Jeyaram Sankar Gurusamy \(HCL\)" <jeyaramg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71FB1.FA8A0605
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For proposed commands in the spreadsheet:

1.	I would encourage you to limit the number of command verbs and
use the same names.  As an example, you are proposing that we change
'volume online' with 'volume set online'.  We have a verb called 'volume
modify' and I don't see why we would add a verb 'set'.
2.	We have been removing the usage of both 'add' and 'create' as
another example.

=20

In the functional spec

1.	The related docs links do not work.
2.	In 4.2.1, it would be best to have variable-length structs than
to hardwire the maximum string length into the payload.  Dimensioning
structs to their max possible size ends up transfering way to much
unused stuff.  I'm guessing that this is used because of the needs to
know the offsets mentioned in section 4.4.5....see my comment below.
3.	Also in 4.2.1, while this is an example, we must following our
coding conventions and commenting rules.
4.	4.3 refers to a date in the past.  The implication is that this
work should be available now and in the document somewhere.
5.	4.4.1 is unclear to me how this helps.  Probably needs to be
explained face-to-face but it's not obvious how this saves anything.
6.	As useful rule is that any parameter that can be set via create
should be settable by modify, and vice versa.  If you following this at
the mgmt layer you will naturally use the same parsing routines and
shares data structures.  While there may be missing internal logic to
support modifying some create parameter, this should be an easy knob to
turn on/off at the cli/gui level and should not impact the
implementation rules.
7.	In 4.4.3, 7.4 why 32-bit boundary?  Why not 64-bit, for uint64
data types or something else?
8.	How are error messages and related error codes to be handled?
9.	In 4.4.5 I'd like to know why we cannot use one of the many
existing command parsers available?  Why is knowing the offset such a
key thing?

=20

=20

=20

________________________________

From: Charissa Willard=20
Sent: Wednesday, December 06, 2006 4:33 PM
To: dl-Design Review
Cc: Ravi Kumar (HCL); Jeyaram Sankar Gurusamy (HCL)
Subject: CLI Refactoring Project: cli command list and parsing library
functional spec

=20

All,

=20

The CLI Refactoring project was launched to provide cli command
consistency in addition to refactoring the code that supports the
commands. The basic requirements are as follows:

=20

1.) The first requirement is to bring consistency to the cli commands
and their options. The list of proposed cli commands can be found in the
attached CLI-list.doc file.=20

=20

2.) The inclusion of a command line parsing library was also desired.
The main reason for this requirement is to move all of the validation
code currently contained in each command handler into a common
validation module. The functional spec for this feature is also
attached.=20

=20

3.) The next feature is to produce a common management API that can
support the web-ui and SNMP at a minimum. This is also discussed in the
attached functional spec. A separate functional spec will be coming out
soon for this feature.

=20

4.) One of the main requirements for the management API is to provide
support for a transactional model, primarily for the cluster DB. This is
mentioned in the problem statement under item 5 in the parsing library
FS. It serves as a placeholder to begin work to define this model.

=20

5.) Note that the nfxsh will eventually be replaced, but as to when has
not been determined.

=20

These documents can also be found at \\Mightydog\Software\CLI
Refactoring <file:///\\Mightydog\Software\CLI%20Refactoring> .
=20
Please review these documents and provide any comments, concerns and
suggestions for these requirements and their proposed solution.
=20
Regards,
Charissa
=20

------_=_NextPart_001_01C71FB1.FA8A0605
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Courier New";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:437412502;
	mso-list-type:hybrid;
	mso-list-template-ids:-1672709800 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:658382280;
	mso-list-type:hybrid;
	mso-list-template-ids:2145309344 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For proposed commands in the =
spreadsheet:<o:p></o:p></span></font></p>

<ol style=3D'margin-top:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level1 =
lfo1'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
     would encourage you to limit the number of command verbs and use =
the same
     names. &nbsp;As an example, you are proposing that we change =
&#8216;volume
     online&#8217; with &#8216;volume set online&#8217;. &nbsp;We have a =
verb
     called &#8216;volume modify&#8217; and I don&#8217;t see why we =
would add
     a verb &#8216;set&#8217;.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level1 =
lfo1'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>We have
     been removing the usage of both &#8216;add&#8217; and =
&#8216;create&#8217;
     as another example.<o:p></o:p></span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the functional =
spec<o:p></o:p></span></font></p>

<ol style=3D'margin-top:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>The
     related docs links do not work.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>In
     4.2.1, it would be best to have variable-length structs than to =
hardwire
     the maximum string length into the payload. &nbsp;Dimensioning =
structs to
     their max possible size ends up transfering way to much unused =
stuff.&nbsp;
     I&#8217;m guessing that this is used because of the needs to know =
the
     offsets mentioned in section 4.4.5&#8230;.see my comment =
below.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Also
     in 4.2.1, while this is an example, we must following our coding
     conventions and commenting rules.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>4.3
     refers to a date in the past. &nbsp;The implication is that this =
work
     should be available now and in the document =
somewhere.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>4.4.1
     is unclear to me how this helps. &nbsp;Probably needs to be =
explained
     face-to-face but it&#8217;s not obvious how this saves =
anything.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>As
     useful rule is that any parameter that can be set via create should =
be
     settable by modify, and vice versa. &nbsp;If you following this at =
the
     mgmt layer you will naturally use the same parsing routines and =
shares
     data structures.&nbsp; While there may be missing internal logic to
     support modifying some create parameter, this should be an easy =
knob to
     turn on/off at the cli/gui level and should not impact the =
implementation
     rules.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>In
     4.4.3, 7.4 why 32-bit boundary?&nbsp; Why not 64-bit, for uint64 =
data
     types or something else?<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>How
     are error messages and related error codes to be =
handled?<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 =
lfo2'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>In 4.4.5
     I&#8217;d like to know why we cannot use one of the many existing =
command
     parsers available? &nbsp;Why is knowing the offset such a key =
thing?<o:p></o:p></span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
face=3DTahoma><span
style=3D'font-family:Tahoma'> Charissa Willard <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, December =
06, 2006
4:33 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> dl-Design Review<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ravi Kumar (HCL); =
<st1:PersonName
w:st=3D"on">Jeyaram Sankar Gurusamy</st1:PersonName> (HCL)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> CLI Refactoring =
Project:
cli command list and parsing library functional spec</span></font><font =
size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3D"Courier New"><span =
style=3D'font-size:9.0pt'>All,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3D"Courier New"><span =
style=3D'font-size:9.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>The
CLI Refactoring project was launched to provide cli command consistency =
in
addition to refactoring the code that supports the commands. The basic
requirements are as follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>1.)
The first requirement is to bring consistency to the cli commands and =
their
options. The list of proposed cli commands can be found in the attached
CLI-list.doc file. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>2.)
The inclusion of a command line parsing library was also desired. The =
main
reason for this requirement is to move all of the validation code =
currently
contained in each command handler into a common validation module. The
functional spec for this feature is also attached. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>3.)
The next feature is to produce a common management API that can support =
the web-ui
and SNMP at a minimum. This is also discussed in the attached functional =
spec.
A separate functional spec will be coming out soon for this =
feature.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.)
One of the main requirements for the management API is to provide =
support for a
transactional model, primarily for the cluster DB. This is mentioned in =
the
problem statement under item 5 in the parsing library FS. It serves as a
placeholder to begin work to define this =
model.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>5.)
Note that the nfxsh will eventually be replaced, but as to when has not =
been
determined.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>These documents can also be found at <a
href=3D"file:///\\Mightydog\Software\CLI%20Refactoring">\\Mightydog\Softw=
are\CLI Refactoring</a>.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Please =
review these documents and provide any comments, concerns and =
suggestions for these requirements and their proposed =
solution.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Regards,<o:p></o:p></span></font></pre><pre><f=
ont
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Charissa<o:p></o:p></span></font></pre><pre><f=
ont
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></div>

</body>

</html>

------_=_NextPart_001_01C71FB1.FA8A0605--
